Cryptographic erasure of selected encrypted data

ABSTRACT

Exemplary method, system, and computer program product embodiments for cryptographic erasure of selected encrypted data are provided. In one embodiment, by way of example only, data files are configured with a derived key. The derived keys adapted to be individually shredded in a subsequent erasure operation. The derived key allows for cryptographic erasure of the selected encrypted data in the data files without necessitating at least one of removal and rewrite of retained data. Additional system and computer program product embodiments are disclosed and provide related advantages.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to computers, and moreparticularly, to cryptographic erasure of selected encrypted data in acomputing environment.

2. Description of the Related Art

In today's society, computer systems are commonplace. Computer systemsmay be found in the workplace, at home, or at school. Computer systemsmay include data storage systems, or disk storage systems, to processand store data. In recent years, both software and hardware technologieshave experienced amazing advancement. With the new technology, more andmore functions are added and greater convenience is provided for usewith these computer systems. Historically, data has been stored on localstorage devices, such as tape drives, hard disk drives (HDDs), andremovable media such as compact discs (CDs) and digital versatile discs(DVDs). With increasing demand for faster, more powerful and moreefficient ways to store and retrieve information, encryption andcomplete erasure of selected data within the various storage system ofthe computing environment is becoming a key challenge for many computersystems.

SUMMARY OF THE DESCRIBED EMBODIMENTS

As the use of data processing systems has become more prevalent, thetechniques used to store and manage data, produced by such dataprocessing systems, have evolved. One mechanism for storing andproviding access to such data is the tape storage system. A conventionaltape storage system comprises a tape storage drive, such as the 3592Enterprise Tape System provided by International Business MachinesCorporation of Armonk, N.Y., and a removable tape data storage mediumupon which data may be stored. It is frequently desirable to controlaccess (e.g., to prevent data from being accessed or to otherwiseobscure the data's content or meaning) to data stored within a datasystem, such as a removable tape data storage media in order to preventunauthorized access.

Accordingly, and in view of the foregoing, various exemplary method,system, and computer program product embodiments for cryptographicerasure of selected encrypted data are provided. In one embodiment, byway of example only, data files are configured with a derived key. Thederived keys adapted to be individually shredded in a subsequent erasureoperation. The derived key allows for cryptographic erasure of theselected encrypted data in the data files without necessitating at leastone of removal and rewrite of retained data. Additional system andcomputer program product embodiments are disclosed and provide relatedadvantages.

The foregoing summary has been provided to introduce a selection ofconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used as an aid in determining the scope of the claimedsubject matter. The claimed subject matter is not limited toimplementations that solve any or all disadvantages noted in thebackground.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsthat are illustrated in the appended drawings. Understanding that thesedrawings depict embodiments of the invention and are not therefore to beconsidered to be limiting of its scope, the invention will be describedand explained with additional specificity and detail through the use ofthe accompanying drawings, in which:

FIG. 1A illustrates a computer storage environment having a storagedevice in which aspects of the present invention may be realized;

FIG. 1B illustrates a high-level block-diagram representation of anenterprise including a tape storage drive apparatus in which aspects ofthe present invention may be realized;

FIG. 2 illustrates an exemplary block diagram showing a hardwarestructure of a data storage system in a computer system in which aspectsof the present invention may be realized;

FIG. 3 illustrates an exemplary block diagram of a tape storage driveapparatus in which aspects of the present invention may be realized;

FIG. 4 is a flowchart illustrating an exemplary method for cryptographicerasure of selected encrypted data; and

FIG. 5 is a flowchart illustrating an exemplary method for cryptographicerasure of selected encrypted data with derived keys.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

As mentioned previously, as the use of data processing systems hasbecome more prevalent, the techniques used to store and manage dataproduced by such data processing systems have evolved. One mechanism forstoring and providing access to such data is the tape storage system. Aconventional tape storage system comprises a tape storage drive such asthe 3592 Enterprise Tape System provided by International BusinessMachines Corporation of Armonk, N.Y. and a removable tape data storagemedium upon which data may be stored. It is frequently desirable tocontrol access (e.g., to prevent data from being accessed or tootherwise obscure the data's content or meaning) to data stored within adata system, such as a removable tape data storage media in order toprevent unauthorized access. For example, archives of data are storedfor compliance reasons that may have legal requirement to retain a pieceof data for some period of time. As an example, in some cases, to becompliant with Health Insurance Portability and Accountability Act(HIPAA) regulations, radiological images of a patient may have to bekept for the life of the patient plus two years. For illustrationpurposes, consider the following scenario demonstrating compliance withsuch regulations. First, all the radiological images created at somehospital may be copied to a tape storage system for disaster recoveryreasons. It may be assumed that all the radiological images are writtenout at the earliest opportunity, until a given tape cartridge is full.Subsequent radiological images may be loaded on another tape cartridgeuntil the tape cartridge reaches a maximum capacity. All theradiological images on a given tape were taken in a given time periodand so are temporally related. Such practices demonstrate satisfactorylower costs for the 2^(nd) (or 3^(rd)) copy of the data for disasterrecovery purposes. However, a patient that has an extended hospitalstay, which has required many radiological images collected over manydays, may have different images stored on at least 20 different tapes.If the patient dies, two years after death, the HIPAA requirement forretention of those images expires, so the files may be deleted. In fact,it may be desired that the images be deleted as soon as possible. It mayalso be desired that the images not only be deleted, but alsocryptographically (secure) erased, so thoroughly and definitively, thatas a practical matter the images may never be recovered or retried, noteven with forensic means.

Thus, the mechanisms of the present invention extend the functionalityof a tape drive (such as an Linear Tape-Open “LTO” LTO-5 drive) and anapplication or piece of middleware (such as linear tape file system“LTFS”) to enable data to be cryptographically erased selectively from atape cartridge without having to rewrite or move data which is to beretained, even if that data is written immediately before or after thedata being erased. While the illustrated embodiments describe theimplementation of the present invention in LTO-5, the same concepts maybe applied to LTO-6, Jaguar (JAG) Jag-3, Jag-4, or an Oracle tape drive(such as T10000). The concepts may also be used with other seriallywritten storage media such as a writeable CD or DVD. Furthermore, whilethe present invention is being described specifically with respect tohow the present invention might be implemented with a linear tape filingsystem (LTFS), the illustrated embodiments may be applied to TivoliStorage Manager (TSM), Intel Architecture (IA), Scale Out NetworkAttached Storage (SoNAS), Quantum's StorNext, and/or any other tapeusing application. Moreover, a secure erase for disk may be applied tostored data in a given sector for a given data entity (e.g. file) thatmay be definitively overwritten multiple times, with multiple differentdata patterns, to eliminate any chance for data recovery, even byforensic means.

Turning to FIG. 1A, an example of a computer system 10 is depicted inwhich aspects of the present invention may be realized. Computer system10 includes central processing unit (CPU) 12, which is connected to massstorage device(s) 14 and memory device 16. Mass storage devices mayinclude hard disk drive (HDD) devices, which may be configured in aredundant array of independent disks (RAID). Memory device 16 mayinclude such memory as electrically erasable programmable read onlymemory (EEPROM) or a host of related devices. Memory device 16 and massstorage device 14 are connected to CPU 12 via a signal-bearing medium.In addition, CPU 12 is connected through communication port 18 to acommunication network 20, having an attached plurality of additionalcomputer systems 22 and 24. The computer system 10 may include one ormore processor devices (e.g., CPU 12) and additional memory devices 16for each individual component of the computer system 10.

FIG. 1B is a high-level block-diagram showing a representation of anenterprise including a tape storage drive apparatus in which aspects ofthe present invention may be realized. Enterprise 100 of FIG. 1comprises a number of host data processing systems (e.g., server dataprocessing systems 102 and associated client data processing systems104), which are communicatively coupled together via a first networkinterconnect (e.g., local area network or “LAN” interconnect 106) asshown. Server data processing systems 102 of the depicted embodiment arefurther coupled to a storage subsystem 108 including a number of datastorage devices and a second network interconnect (e.g., storage areanetwork or “SAN” interconnect 112).

In the exemplary embodiment of FIG. 1, storage subsystem 108 is depictedas including a single tape data storage device 110. In alternativeembodiments of the present invention however, storage subsystem 108 mayinclude any number and type of data storage device (e.g., individualdisk drives, tape drives, disk arrays, tape arrays, RAID arraysubsystems, robotic tape libraries, filers, file servers)communicatively coupled together and to server data processing systems102 via a storage interconnect (SAN interconnect 112), such as a fiberchannel (FC) switch, switch fabric, arbitrated loop, or the like. Serverdata processing system 102A of the embodiment of FIG. 1 comprises anapplication server (e.g., a database server) to provide core operationalfunctionality to one or more of client data processing systems 104A-104N(where “N” is a positive integer) and server data processing system 102Bcomprises another server (e.g., a cluster failover server,load-balancing server, backup server, or the like).

Tape data storage device 110 of the depicted embodiment is coupled toSAN interconnect 112 via a communication link as shown. Eachcommunication link may comprise any of a number of communication mediacapable of transmitting one or more electrical, optical, and/oracoustical propagated signals (e.g., copper wiring, fiber optic cable,or the like) between SAN interconnect 112 and a communication port oftape data storage device 110.

In the illustrated embodiment, tape data storage device 110 and serverdata processing system 102A are configured with sufficient functionalityto control and/or manage the access provided to data of a tape datastorage medium within a tape cartridge coupled with tape data storagedevice 110 as will be further described herein. Utilizing one or moreembodiments of the present invention, access to data of a tape datastorage medium so-associated with tape data storage device may berestricted and/or host data processing systems accessing such data maybe identified.

While a conventional SAN-type interconnect (SAN interconnect 112) hasbeen specifically depicted in the embodiment of FIG. 1, otherinterconnects (e.g., direct connection, local, metropolitan, and/orwide-area networks) and other protocols (e.g., FICON, ESCON, SSA, or thelike) may be utilized. Moreover, while a particular number andarrangement of elements have been illustrated with respect to enterprise100 of FIG. 1, it should be appreciated that embodiments of the presentinvention are not limited to enterprises, systems, or data storagedevices having any particular number, type, or arrangement of componentsother than as explicitly recited herein and so may encompass a widevariety of system types, architectures, and form factors.

In an alternative embodiment, FIG. 2 is an exemplary block diagram 200showing a hardware structure of a data storage system in a computersystem in which aspects of the present invention may be realized. Hostcomputers 210, 220, 225, are shown, each acting as a central processingunit for performing data processing as part of a data storage system200. The hosts (physical or virtual devices), 210, 220, and 225 may beone or more new physical devices or logical devices to accomplish thepurposes of the present invention in the data storage system 200. In oneembodiment, by way of example only, a data storage system 200 may beimplemented as IBM® System Storage™ DS8000™. A Network connection 260may be a fibre channel fabric, a fibre channel point to point link, afibre channel over ethernet fabric or point to point link, a FICON orESCON I/O interface, any other I/O interface type, a wireless network, awired network, a LAN, a WAN, heterogeneous, homogeneous, public (i.e.the Internet), private, or any combination thereof. The hosts, 210, 220,and 225 may be local or distributed among one or more locations and maybe equipped with any type of fabric (or fabric channel) (not shown inFIG. 2) or network adapter 260 to the storage controller 240, such asFibre channel, FICON, ESCON, Ethernet, fiber optic, wireless, or coaxialadapters. Data storage system 200 is accordingly equipped with asuitable fabric (not shown in FIG. 2) or network adapter 260 tocommunicate. Data storage system 200 is depicted in FIG. 2 comprisingstorage controller 240 and storage 230.

To facilitate a clearer understanding of the methods described herein,storage controller 240 is shown in FIG. 2 as a single processing unit,including a microprocessor 242, system memory 243 and nonvolatilestorage (“NVS”) 216, which will be described in more detail below. It isnoted that in some embodiments, storage controller 240 is comprised ofmultiple processing units, each with their own processor complex andsystem memory, and interconnected by a dedicated network within datastorage system 200. Storage 230 may be comprised of one or more storagedevices, such as storage arrays, which are connected to storagecontroller 240 by a storage network.

In some embodiments, the devices included in storage 230 may beconnected in a loop architecture. Storage controller 240 manages storage230 and facilitates the processing of write and read requests intendedfor storage 230. The system memory 243 of storage controller 240 storesprogram instructions and data, which the processor 242 may access forexecuting functions and method steps of the present invention forexecuting and managing storage 230 as described herein. In oneembodiment, system memory 243 includes, is in association with, or is incommunication with the operation software 250 for performing methods andoperations described herein. As shown in FIG. 2, system memory 243 mayalso include or be in communication with a cache 245 for storage 230,also referred to herein as a “cache memory”, for buffering “write data”and “read data”, which respectively refer to write/read requests andtheir associated data. In one embodiment, cache 245 is allocated in adevice external to system memory 243, yet remains accessible bymicroprocessor 242 and may serve to provide additional security againstdata loss, in addition to carrying out the operations as described inherein.

In some embodiments, cache 245 is implemented with a volatile memory andnon-volatile memory and coupled to microprocessor 242 via a local bus(not shown in FIG. 2) for enhanced performance of data storage system200. The NVS 216 included in data storage controller is accessible bymicroprocessor 242 and serves to provide additional support foroperations and execution of the present invention as described in otherfigures. The NVS 216, may also referred to as a “persistent” cache, or“cache memory” and is implemented with nonvolatile memory that may ormay not utilize external power to retain data stored therein. The NVSmay be stored in and with the cache 245 for any purposes suited toaccomplish the objectives of the present invention. In some embodiments,a backup power source (not shown in FIG. 2), such as a battery, suppliesNVS 216 with sufficient power to retain the data stored therein in caseof power loss to data storage system 200. In certain embodiments, thecapacity of NVS 216 is less than or equal to the total capacity of cache245.

Storage 230 may be physically comprised of one or more storage devices,such as storage arrays. A storage array is a logical grouping ofindividual storage devices, such as a hard disk. In certain embodiments,storage 230 is comprised of a JBOD (Just a Bunch of Disks) array or aRAID (Redundant Array of Independent Disks) array. A collection ofphysical storage arrays may be further combined to form a rank, whichdissociates the physical storage from the logical configuration. Thestorage space in a rank may be allocated into logical volumes, whichdefine the storage location specified in a write/read request. Moreover,the tape data storage device 110 (see FIG. 1B), as described in FIG. 1Band FIG. 3, may be implemented with the architecture described in FIG.2.

In one embodiment, by way of example only, the storage system as shownin FIG. 2 may include a logical volume, or simply “volume,” and may havedifferent kinds of allocations. Storage 230 a, 230 b and 230 n are shownas ranks in data storage system 200, and are referred to herein as rank230 a, 230 b and 230 n. Ranks may be local to data storage system 200,or may be located at a physically remote location. In other words, alocal storage controller may connect with a remote storage controllerand manage storage at the remote location. Rank 230 a is shownconfigured with two entire volumes, 234 and 236, as well as one partialvolume 232 a. Rank 230 b is shown with another partial volume 232 b.Thus volume 232 is allocated across ranks 230 a and 230 b. Rank 230 n isshown as being fully allocated to volume 238—that is, rank 230 n refersto the entire physical storage for volume 238. From the above examples,it will be appreciated that a rank may be configured to include one ormore partial and/or entire volumes. Volumes and ranks may further bedivided into so-called “tracks,” which represent a fixed block ofstorage. A track is therefore associated with a given volume and may begiven a given rank.

The storage controller 240 may include a cryptographic erasure module.The cryptographic erasure module 255, derived key module 257, and KSDSmodule 259 may work in conjunction with each and every component of thestorage controller 240, the hosts 210, 220, 225, and storage devices230. Both the cryptographic erasure module 255, derived key module 257,and KSDS module 259 may be structurally one complete module or may beassociated and/or included with other individual modules. Thecryptographic erasure module 255, derived key module 257, and KSDSmodule 259 may also be located in the cache 245 or other components.

The storage controller 240 includes a control switch 241 for controllingthe fiber channel protocol to the host computers 210, 220, 225, amicroprocessor 242 for controlling all the storage controller 240, anonvolatile control memory 243 for storing a microprogram (operationsoftware) 250 for controlling the operation of storage controller 240,data for control and each table described later, cache 245 fortemporarily storing (buffering) data, and buffers 244 for assisting thecache 245 to read and write data, a control switch 241 for controlling aprotocol to control data transfer to or from the storage devices 230,and cryptographic erasure module 255, derived key module 257, and KSDSmodule 259 in which information may be set. Multiple buffers 244 may beimplemented with the present invention to assist with the operations asdescribed herein.

In one embodiment, the host computers or one or more physical or virtualdevices, 210, 220, 225 and the storage controller 240 are connectedthrough a network adaptor (this could be a fibre channel) 260 as aninterface i.e., via at least one switch called “fabric.” In oneembodiment, the operation of the system shown in FIG. 2 will bedescribed. The microprocessor 242 may control the memory 243 to storecommand information from the host device (physical or virtual) 210 andinformation for identifying the host device (physical or virtual) 210.The control switch 241, the buffers 244, the cache 245, the operatingsoftware 250, the microprocessor 242, memory 243, NVS 216, cryptographicerasure module 255, derived key module 257, and KSDS module 259 are incommunication with each other and may be separate or one individualcomponent(s). Also, several, if not all of the components, such as theoperation software 250 may be included with the memory 243. Each of thecomponents within the devices shown may be linked together and may be incommunication with each other for purposes suited to the presentinvention.

FIG. 3 is a block diagram 300 showing a tape storage drive apparatus inwhich aspects of the present invention may be realized. The tape datastorage device 300 comprises a removable data storage tape cartridge 302and a communication interface (e.g., host data processing systeminterface (I/F) 306) to communicatively couple tape data storage device300 to one or more host data processing systems or associatedcommunication channels (e.g., SAN interconnect 112).

The host data processing system I/F 306 is configured to receiveinput/output (I/O) operation requests (e.g., “read” and/or “write”requests), and process such requests in an appropriate manner to controlor “manage” access to a tape data storage medium 308 (e.g., magnetictape) of removable data storage tape cartridge 302 as described herein.In addition to tape data storage medium 308, data storage tape cartridge302 comprises a cartridge memory (CM) module 309. CM module 309comprises a passive, contactless silicon storage device utilized tostore data about the tape cartridge (removable data storage tapecartridge 302) in which it resides. Exemplary data may include, forexample, data indicating the associated tape cartridge's volume serialnumber (VOLSER), the “type” of data storage medium within the cartridge,and the data, if any, which is stored thereon.

Tape data storage medium 308 of removable data storage tape cartridge302 is routed in proximity to a tape access (e.g., read/write) head 310utilizing media transport reels 312 and 314 and one or more mediatransport motors 316 as shown. The tape access head 310 is configured toread data from and write data to tape data storage medium 308 and totemporarily store or “stage” such data within a buffer 318 (e.g., one ormore “read-ahead” or staging buffers). The tape data storage device 300further comprises a controller or control unit 320. Control unit 320controls and manages data flow, formatting, and data storage subsystemoperation via control signals issued to one or more of host dataprocessing system I/F 306, buffer 318, media transport motors 316,and/or CM I/F 322 utilized to access CM 309 in order to cause one ormore method or process embodiments of the present invention oroperations thereof to be performed. In another embodiment, such controlfunctionality may be incorporated into one or more of host dataprocessing system I/F 30, and control unit 320.

In the current state of the art, there are no methods for a secure erasefor tape, particularly for modern (e.g. LTO based) tape drives thatwould need to definitively erase a set of data (e.g., a file), and stillallow reuse of the tape cartridge. First, a standard erase or overwriteof data on tape will logically erase all data downstream of that eraseor overwrite because a tape is a sequential storage media, which cannotbe written out of order (i.e., the tape is not random access from awrite point of view). Second, tracks written to LTO tapes (starting withLTO-2) typically overwrite part of previously written tracks, atechnique known as shingling. (Shingled writing allows forwriting/erasing with a write head wider than the data track to be left(i.e. the residual track width), which enables backward writing.)Shingled writing requires tracks to be written in a certain order (justas the shingles on a house must be installed in a certain order—thosefurthest from the peak first, etc.). Shingling essentially relies on thefact that data is written sequentially, and conversely non-sequentialwriting is hard to imagine in the face of a shingled writing scheme.Third, a standard erase or overwrite of data on tape may consistentlyleave a slice of the original data unerased and/or not overwritten. Thisis because environmental changes (such as a change in the temperature orhumidity) can cause systematic mechanical change (e.g. width of the taperelative to the width of the write head). Fourth, a standard erase oroverwrite may be interrupted by a servo error, which causes the currentto the write head be degated. In the user area, this functionality maybe required to prevent overwrite of previously written data tracks. Yet,in trying to guarantee that a previously written data set isoverwritten, this is distinctly problematic—because a stretch of nearly4 meters of tape can go unerased (or un-overwritten). This canpotentially leave a significant amount of old data on tape in fullyreadable form.

To address these inefficiencies, encryption may be applied. Encryptionmay provide for cryptographic erasure of data because a key may be usedto encrypt data that is irretrievably lost, so that there may be nofeasible way to read the encrypted data. Application Managed Encryption(AME) is an encryption method that may be used, but the AME requires anapplication to manage all the encryption keys and requires that theapplication have a persistent database to retain those encryption keysand some applications (such as LFTS) do not. Even if an application(such as TSM) provided a persistent database, the number of keys thatwould have to be retained (e.g. up to 10 million per cartridge, at up to40 bytes each, requiring up to 400 MB per cartridge) would beexcessively onerous. Moreover, many applications designed to enforcecompliance regulations essentially need to manage the data as files,i.e. either interfacing with a NAS box or writing to a file system via aPOSIX interface. These types of applications are typically not capableof handling tape at all.

For an LTFS, middleware may potentially allow File Using Applications towrite file data to tape. However, from a compliance point of view,problems arise when a File Using Application requests a file to bedeleted. One option is for the LTFS by itself to simply remove the filefrom the Index File and so the data would be fully recoverable. Yetthere is no secure erase option to definitively erase a file. So thesecond option is to retain all the currently valid files and move allthe valid files to another cartridge and then destroy the originalcartridge. However, this is not an acceptable method due to high costsin both time (to reclaim the cartridge) and dollars (to have to destroyand then replace the original cartridge because the tape is notreusable). With a strong enough magnet, it may conceivably bulk erase atape (e.g., with the coercivity of recent LTO tapes this requires a verystrong magnet), but in the case of LTO, or tape technology based on LTO(such as the IBM® Jag drives or Oracle T10000), this will also cause thetracking servo pattern to be erased, thus rendering the tape cartridgeuseless (i.e. it is not reusable). So this too is costly by renderingthe tape non-reusable. Thus, a need exists for the ability toselectively delete data archived to tape without having to delete orrewrite all the data written to tape.

There are many use cases where this capability is desirable—one of theseis the case where there is a need for assured deletion of some subset ofthe data on tape, even though other data on the same tape must beretained. Because of the limitations with erasure/overwrite capabilityof today's tape technology, it is not acceptable since many customersrequire secure erase capability that definitively and forever erases thedata such that it can never be recovered, even if forensic means areused. As an example, because modern tape does not support a true SecureErase, some military users of modern tape never trust the data on a tapeto be erased or unrecoverable, and so will not allow it to betransported outside of some secure facility once it has been writtenwith data of some classification (e.g. perhaps Top Secret).

It should be note that when archive data is stored as files to a disk,the files may not simply be deleted because only the pointer to the datais deleted, and it does not cause the data itself to be erased oroverwritten. Moreover, even if a given sector is overwritten once, thisdoes not necessarily mean the data is irrevocably lost becausesometimes, due to mechanical tolerances and environmental changes, thereis not an exact overwrite. In other words, there may be some remnantslice of the data sector that is still recoverable by forensic means.

Modern tape drives such as LTO-4, LTO-5, Jag-2, and Jag-3 may supportboth application transparent (e.g., transparent encryption or LibraryManaged Encryption (LME)) and Application Managed Encryption (AME). Inone embodiment, tape drive encryption functionality is provided. TheLTO-4 may use encryption keys served to it directly and does not storeencryption keys. LTO-4 technology may support the use of multipleencryption keys on a single tape cartridge, but restrict key changes inthat they are only allowed on dataset boundaries, which limit the numberof keys that may be used to less than one million. In LTO-4, anencryption key may either be provided by a key manager (in LME) or by anapplication (in AME). The encryption key may be served to the drive. Theencryption key served to the drive may then be used directly—i.e. toencrypt data written to tape, or to decrypt data read from tape.

The LTO-5 may encryption keys indirectly and, since it may store theencryption keys it receives, it may store something for each key servedto it. Multiple encryption keys may be used on a single tape cartridge,but key changes may only occur on dataset boundaries. An encryption keymay either be provided by a key manager (in LME) or by an application(in AME). An encryption key is served to the drive, but the tape drivedoes not use this encryption key directly. Rather it may generate itsown key, which is used to actually encrypt (or later decrypt) the data.The generated key is then wrapped with the served key, and that wrappedkey is then stored to the Dataset Information Table (DSIT) of eachdataset encrypted.

The Jag-2 and Jag-3 may support AME in essentially the same way thatLTO-4 does, but supports transparent tape encryption (e.g. LME) quitedifferently. In the case of LME, LME may receive and store one or twowrapped key structures from a key manager for each encryption key used.Each wrapped key structure may be referred to as an Externally EncryptedData Key (EEDK) and is essentially an opaque blob to the tape drive,since it cannot decrypt them itself, which stores it. When Jag drivesare used to do LME, a single encryption key (the key which is wrapped tocreate the EEDKs) may be used to encrypt all the data on a tapecartridge. (That encryption key is only stored as EEDKs to the tapecartridge, so the tape cartridges are essentially used as a distributedkey store.) Thus, Jag drives may be programmed to allow use of multipleencryption keys per cartridge. However, the multiple key functionalitymay go unused because the only way the drive may know when to switchfrom using one key to another is if an application issued a command toswitch.

Thus, because tape drives are essentially limited to using only oneencryption key per cartridge, in one embodiment, the tape drives areallowed to generate many encryption keys at a time and store themtogether in one or more special datasets. These special datasets areknown as Key Store DataSet (KSDS). The EKDS's may be stored only in theHousekeeping region (from LP2 to LP3), though they potentially may bestored elsewhere (e.g. in a separate partition). Since some tape drivesuse 256 bit keys to do encryption, to store a truly random key, a full256 bits (=32 bytes) is required. The illustrated embodiments mayadditionally store some form of checksum with each key. If an 8-bytecheck sum is used, then 40 bytes are needed total to store each key. Thedataset size used for LTO-5 allows storage of 2,472,040 bytes of data,which means 61801 keys, which require 40 bytes each to be stored (thisis just more than 60×1024 so it may be assumed, as an example only, thatthe number of keys per KSDS as 60K). Furthermore, for illustrationpurposes, it may be assumed that one KSDS is created at a time but moreKSDSs are created, as needed, up to some maximum number of KSDS that canbe stored, depending on where they are stored.

Moreover, at least 192 KSDSs may be stored resiliently and in a specialway in the LP2-LP3 region, which means more than 10 million keys may bestored. Note that LTO-6 may store 3 Terabyte (TB) natively percartridge, so 3 million 1 megabyte (MB) files (before DSIT) or perhapsas many as 10 million 1 MB files after compression may be stored. Thus,as long as the minimum file (or file set) size is appropriate (in theMBs or larger) the LTO-6 tape cartridge with files may be filled, eachencrypted with a unique key. If the files are very small in size (e.g. 4KB) or compressible, the illustrated embodiments may run out of keys forany reasonable number of KSDSs if an attempt is made to uniquely encrypteach file and yet still fill a cartridge. The AME on LTO may requirethat all key changes be on a dataset boundary—which means each time anew key is used, essentially 2.4 MB of tape storage space is consumed,even if the amount of data written between key changes is significantlyless. As will be discussed below, each KSDS may be written more thanonce for redundancy. Each KSDS may be storing encryption keys “in theclear”. Note that the methodology above can be combined with standardtransparent encryption, such as LME. In that case, the key served to itby the key manager is used (either directly or indirectly) to encryptthe KSDS such that all the keys stored there are encrypted and thusunreadable, even if a KSDS could be successfully copied off of a tapecartridge.

There are two ways that the multiple encryption key method can beimplemented. First, by an anonymous method to allow applicationtransparency. If the tape drive can detect where one data construct endsand the next starts, it may potentially encrypt one set of data with onekey, and the next set with a different key. While this is not generallypossible, some cases allow for this possibility. For example, if anapplication wrote files one at a time to tape in a specific way, suchthat all the file data is written, and then a perform a File Mark, thenthe tape drive may change encryption keys at each File Mark andeffectively encrypt each file with a different encryption key. However,this process presents several challenges. First, the files are notwritten in such a way that the tape drive may automatically detectswhere to switch keys. Second, the drive is modified to switch keysautomatically. As an example, to erase a data block, the data block arespaced out and then an erase is performed. The drive would then have tosee what is happening, determine the key used to encrypt that set ofdata (e.g. by reading the DSIT), then go back and delete the appropriatekey. However, this is not a natural drive operation since the eraseviolates the tape access method. Another option available is that keyswitches may be noted and recorded in the KSDS. For example, the datastored with each key could be extended to include either the (Total)Record Count or (Total) Filemark Count or (Total) Block Count (sum orRecord and Block) of the first block of data encrypted with thatencryption key, as well as the number of blocks which use that key. Inthis case, a modified shred may be used, where an application provides a(Total) Record/Filemark/Block Count with the key shred request, and thetape drive determines which key to shred. The extra overhead of storingthe Record/Filemark/Block Count would somewhat reduce the number ofencryption keys that can be stored for a given number of KSDSs.Requiring support for a new extended Key Shred means the mechanisms needto be modified.

In one embodiment, the Application (or middleware) assisted method isprovided. Each application or piece of middleware may be modified to usethe multiple key capabilities. A command may be issued by theapplication that effectively indicates to the tape drive to witch tousing the next encryption key and return a label that may be used in thefuture to refer to that key. By way of example, it is assumed that thecommand is a new extension to one of the existing commands used toprovide encryption keys to the tape drive. Also, it may be assumed thatthe key label returned is either the direct address of that key (e.g.4.351, is essentially a dense version of “use the key at position 351 inKSDS 4”), or something from that which direct address can be used toobtain or derive that direct address in a 1-to-1 way. The application ormiddleware then stores the key label, wherever the application and/ormiddleware decides. In the case of LTFS, the LTFS may store the keylabel back to the tape cartridge as an Extended Attribute (XA)associated with the file to be encrypted—in which case the key label isstored in the Index File written to tape as well. In the case of otherapplications, such as TSM, the key label might be stored to theapplication database which tracks all things associated with a dataentity (like what tape cartridges it is stored to, and where exactly onthose tape cartridges).

Subsequently, in order to later perform a write append to that dataentity (which may be a file), the application or middleware issues acommand, which causes the drive to use the appropriate key by providingthe data entity with the key label. This command essentially indicatesto use the key associated with the key label. In the case of LTFS, if aFile Using Application (FUA) requests that LTFS open a file with writepermissions, then LTFS retrieves the metadata associated with that filefrom the tape cartridge, reads the XA which contains the Key Label, andthen issues a command which provides that Key Label to the drive so itcan fetch the appropriate key to encrypt the data to be appended to thatfile. At some later time, to do a decrypting read of that data entity(which may be a file), the application issues a command, which causesthe drive to use the appropriate key by providing the data entity thekey label. This command essentially indicates to use the key associatedwith the key label. In the case of LTFS, if a File Using Application(FUA) requests that LTFS to read a file, then LTFS retrieves themetadata associated with that file from the tape cartridge, reads the XAwhich contains the Key Label, and then issues a command which providesthe Key Label to the drive.

At some later time, to do a Secure (Cryptographic) Erase of that dataentity (which might be a file), the application issues a command, whichis an extension of the Key Shred command supported by Jag. This commandrequests that the key associated with the key label be shredded. In thecase of LTFS, if a File Using Application (FUA) requests that LTFSdelete a file, then LTFS retrieves the metadata associated with thatfile from the Index File on the tape cartridge, reads the XA, whichcontains the Key Label, and then issues a Key Shred of that Key Labelcommand to the drive. Once that Key Shred operation is completed, andthe original KSDS is overwritten, the encryption key associated withthat file is irretrievably erased, and so the data encrypted with it isunrecoverable. In other words, the selected encrypted data has beencryptographically erased.

As pertaining to the LTFS, by applying the implementations previouslydescribed in the LTFS, the functionality in the LTFS middleware mayallow for some policy mechanism to select whether a given LTFS instanceis to encrypt on a per file basis. A flag may be used in the LTFSconfiguration file with the default state of that flag (which may besimply the absence of that flag) indicating that no encryption is tooccur. If the flag is present and in the proper state, an encryption ona per file basis may be performed. It should be noted that theencryption may require a finer granularity, such that a given LTFSinstance will encrypt some cartridges on a per file basis and not others(e.g. perhaps some subset have to remain in unencrypted). There aremultiple ways this may be accomplished. One such way is to have theencryption flag essentially be a property of the cartridge, such as anXA associated with the file folder, which is the cartridge. In such acase, a cartridge is LTFS formatted and then the XA to encrypt on a perfile basis is set (this may be performed as an extension to the formatcommand, or alternatively by another utility or program after it wasformatted).

When a cartridge is to be encrypted on a per file basis, then each timeLTFS opens a new file to write to it, the tape drive is instructed toswitch to use of the next key and return a label, which the drive mayuse in the future to refer to that key. Note that if this is the firstsuch request, the drive may have to generate keys to create the firstKSDS. Similarly, if the drive has used up all the keys it presently hasavailable, the mechanisms may generate new keys. LTFS then takes thereturned key label and writes it out as a XA of that file by updatingthe Index File.

When a cartridge has a file, which was encrypted on a per file basis,each time LTFS opens that file to write to it, the LTFS instructs thedrive to switch to use of the key with this key label. In this way, thesame key is used to encrypt all the data associated with a file, even ifthat file was modified multiple times and has a present valid extentlist which includes extents which are spread out over multiple differentareas of the tape. It should be noted that when the original file waswritten it was essentially written with the next available key and thekey label was stored. However, when the file is updated, the key labelis read from the XA where it was stored and sent to the drive. In thiscase, LTFS is requesting that updates to the file be encrypted with acertain key (e.g., the key specified by the key label that was sent.)

Similarly, when LTFS needs to read a cartridge that has a file that wasencrypted on a per file basis, the LTFS reads the key label used toencrypt that key from the XA and serves that to the drive andessentially commands to decrypt with the key. In an alternateembodiment, it may be preferable, where the only thing to be done is adecrypting, to read where the LTFS tells the drive to determine whichencryption key to use during a read. The drive can do this by readingthe key label from the DSIT and then using that key label as an indexinto the KSDS to fetch the key and then decrypting with that key. WhenLTFS needs to cryptographically erase a file from the cartridge that wasencrypted on a per file basis, the LTFS reads the key label used toencrypt that key from the XA. The LTFS then provides that to the drivein an extended Shred command—the extension has this command essentiallytelling the drive to “shred the key with this label”. It should be notedthat because all the extents associated with a given file are writtenwith the same key, all extents that ever comprised that file (even thosethat have since been invalidated and so are not listed in the presentvalid extent list) are cryptographically erased when that key isshredded.

Furthermore, it is necessary to securely erase a KSDS. In oneembodiment, the KSDS will only be written in the LP2 to LP3 region whereno user data is written and so logical overwrite is not an issue. Itshould be noted that KSDS data written in the LP2 to LP3 region is notwritten continuously so that upstream KSDS data may be written on thesame wrap as downstream KSDS data without making that KSDS dataunreadable. The KSDS may not be written on every wrap; instead the KSDSmay be laterally dispersed so that shingling is not an issue. The KSDSmay always be written on a wrap which has two empty wraps straddling itso that all three wraps can be erased, which assures that nolongitudinal slice of the KSDS is left unerased. The KSDS may be writtenin a special way that allows a certain amount of toleration of servoerrors. The KSDS may be written such that more than one copy has to beread to recover the keys, so that if one KSDS cannot be overwritten onecan still be certain the keys are not recoverable.

Furthermore, the Key Set DataSets (KSDS's) may only be written to theLP2 to LP3 region. It should be noted that there might be at least 12locations in the LP2-LP3 region that may be used. There may be 20 wrapsper Data Band in LTO-5, 10 forward and 10 reverse. In the case of DataBand 0 these are wraps 1, 3, . . . 19 (forward) and wraps 2, 4, . . . 20(reverse). To address the problem with tolerances, KSDS may not bewritten on every wrap. Instead the KSDS may be written so that theadjacent track on either side may be erased. For example, a KSDS mightbe written in wrap 5. When it comes time to overwrite that KSDS on wrap5, one may erase the necessary length of tape on wraps 3, 5, and 7,which will definitively erase track 5—independent of any reasonableLateral Tape Stability (LTS) or mechanical tolerancing issues. (It isassumed, by way of example only, to use of (relative) wraps 5, 11, and17 on each data band in the LP2-LP3 region of an LTO-5 tape (allowingwrap 1 to be used independently (e.g. for HKDS). Since there are 3 wrapsin each of 4 data bands, this means 12 wraps are written. A given KSDSmay be written four times to a wrap pair. The reverse wrapscorresponding to (5, 11, and 17) to create the pair are (6, 12, and 18).

To address the potential problem with servo errors preventing erasure,consider the following. Since the proposal is to write four shares ofeach KSDS, the KSDS may be divided so that two shares are writtenforward on one wrap and two other shares are written on another wrap inreverse. (Forward writing of the first share could begin on a wrap atLP2, forward writing of the second share could begin at (LP2+LP3)/2 onthat same wrap, reverse writing of the third share could begin at LP3 onanother wrap, and reverse writing of the fourth share could begin at(LP2+LP3)/2 on his same other wrap.) Each share of a KSDS may bedifferent in a special way. A special technique known as a Shamir SecretSharing algorithm (“Shamir”), which allows a key to be split intoshares, may be implemented. In the case of the Shamir algorithm, eachkey share is the same length, which is the length of the original keybeing split (in the case here, the original key and all key shares wouldbe 32 bytes long). Shamir shares may be created such that any key can bedivided into N shares in a special way such that M (<N) of those sharesare required to re-create that key. By way of example only, themechanisms employ use of M=2 and N=4. Thus, each KSDS may be split into4 shares, each of which is different in a special way, and each of whichis written to tape. In this case one, the mechanisms may able to readtwo of them to recover the keys in the original unsplit KSDS.

By way of example only, consider the scenario where the mechanismsproceed systematically to erase the previous written KSDS and replace itwith a new KSDS. The mechanisms may first assume no servo errors. Thus,the first share of the old KSDS is erased, in 3 passes (e.g. todefinitively erase wrap 5 one must erase wraps 3, 5, and 7), and then anoverwrite is performed (e.g. on wrap 3) with the first share of the newKSDS. At this point the old KSDS is still recoverable (since 3 of the 4shares still exist), but the new KSDS is not (since only 1 of theeventual 4 shares are written). Next the second share of the old KSDS iserased, in 3 passes, and then an overwrite operation is performed withthe second share of the new KSDS. At this point the old KSDS is stillrecoverable (since 2 of the 4 shares still exist) as is the new KSDS(since 2 of the eventual 4 shares are now written). Next the third shareof the old KSDS is erased in 3 passes, and then an overwrite operationis performed with the third share of the new KSDS. At this point, theold KSDS is no longer recoverable (since only 1 of the 4 shares stillexist), but the new KSDS is (since only 3 of the eventual 4 shares arewritten). Finally, the fourth share of the old KSDS is erased, in 3passes, and then an overwrite operation is performed with the fourthshare of the new KSDS. At this point the old KSDS no longer exists atall (since 0 of the 4 shares still exist), but the new KSDS is (sinceall 4 shares are written). It should be noted that at no point are thekeys to be retained unrecoverable, even were a write permanent erroroccur.

By way of example only, consider the scenario where a servo erroroccurs, which prevents either definitive erasure of one of the adjacenttracks or continuous overwrite of some KSDS share. First, the tape driveshould monitor whether a servo errors occurs. As previously discussedabove, a set of KSDS's is erased and overwritten (in 3 passes on 3adjacent wraps). Before starting the 3 passes, the mechanisms shouldfirst carefully detect the exact longitudinal extent of the set ofKSDSs—specifically the LPOS at which writing of that set began and theLPOS at which it ended. This action determines the longitudinal extentthat must be definitively erased and overwritten with the new set ofKSDSs. If the Write Gates stays active on all 3 passes for the fulllongitudinal extent of the old set of KSDS, the old set of KSDS is nowconsidered securely erased. However, if the Write Gate is consistently(i.e. even on retry) degated by a servo error such that one of the 3erase/write passes is not continuous then the share of the old set ofKSDSs has to be considered recoverable. Yet there should be at least oneretry on any erase or write pass of a KSDS to determine if on retry itcan not be erased (or written) continuously (i.e. without beinginterrupted by a servo error). If the subsequent erase or write retrysucceeds continuously, secure (cryptographic) erasure of selectencrypted data written to tape for the one write/erase pass should beconsidered to have been completed successfully.

Moreover, consider the scenario where a servo error occurs, whichprevents either definitive erasure of one of the adjacent tracks orcontinuous overwrite of some KSDS share. By way of example only, assumethat servo error occurs on the first share of the KSDS. In such case,the mechanisms of the present invention attempt to perform an erase, in3 passes, of the first share of the old KSDS. There is a servo error,which prevents continuous erasure. Assume, for example, that the newfirst share of the KSDS may be written down stream of the servo error.At this point the old KSDS is still recoverable (all of 3 of the 4 stillexist, and at least a part of the 4^(th) share), but the new KSDS is not(since only 1 of the eventual 4 are written). Assume, for example, thenext 3 copies are erased and overwritten uneventfully. At this point theold KSDS is not recoverable (since only part of one of the 4 copiesexist), and the new KSDS is not (since all 4 copies are written).

It should be noted that at no point are the keys to be retainedunrecoverable, even were a write permanent error occur. It should alsobe noted that the mechanisms described above works so long as only oneof the four shares cannot be overwritten, regardless of which of the 4original copies of the KSDS it was that could not be overwritten—so longas the new copies can be. In the case where servo errors are so severe,the mechanisms cannot write any new share successfully (even when it islongitudinally dispersed via write skipping). Thus, the mechanismscannot the write resulting in a permanent write error. In the veryunlikely case that two of the shares of the old KSDS (the one to becryptographically erased) cannot be overwritten (or over-erased) becauseconsistent serve errors forces the old KSDS to be laterally dispersed(write skipped), then the mechanisms consider that the old KSDS arerecoverable (since 2 of 4 copies are potentially recoverable). When the2^(nd) of these two shares cannot be successfully overerased(over-written), the drive should treat this like a permanent write errorof the new KSDS. In the case of a write permanent error, when trying towrite one of the first two KSDS, then one has not written itsuccessfully and has invalidated the previous KSDS. In this case, allfile data to be retained should be migrated off the bad cartridge onto anew tape cartridge. That involves a decrypting read from the firstcartridge and an encrypting write to the second cartridge. The firstcartridge should then be definitively and irreversibly destroyed (e.g.incinerated) such that even forensic data recovery is not possible. Itshould be noted that the redundancy and resiliency discussed aboveshould make the case of migration and destruction a very rare (e.g. 1 in100,000) exception case.

In one embodiment, it is necessary to prevent the KSDS from being read.All of the significance of the steps discussed above, to definitivelyerase the keys, is reduced if the KSDS may be read and stored externalto the cartridge. To prevent this, the tape drive code operation may bechanged to prevent transfer of KSDS datasets under any normal condition.It should be noted that since the KSDS are outside the user region, theKSDS are not readable with any standard small computer system interface(SCSI) command, but KSDS should not be accessible via any engineering ordebug command supported by drive code shipped to the field. This is adrive microcode control, the intent of which is to prevent a reading ofthe cartridge remotely (e.g. say they hacked into the SAN). If a userhad physical possession of the cartridge, the cartridge may have it readby an instrumentation test stand or via a modified drive. It should benoted that if LME transparent encryption is used on top of thepreviously discussed steps for the per file encryption, then the KSDSitself encrypted—which means the keys in the KSDS are not accessibleunless one has the key which encrypted the KSDS.

Since the tape drive cannot know a priori that it will not receive afuture key change request, the tape drive cannot know if a cartridgewill be uniformly encrypted with a single key, which if a tape drivepresumes use of such a key additional problems and complexities arise.

In one embodiment, the mechanisms described below in method 2, in eitherthe single key or multi-key case, are more flexible and lessproblematic. Thus, consider the following methods.

Exact Controls from a LTO Logical Format POV—Method 1

First, an indication must be given to a tape drive that a user datasetwas protected by a shred key in the KSDS. The Landsat Technical WorkingGroup (LTWG) should determine the best way for this indication, and inone embodiment, the mechanisms may create a new state for the existingencrypted Flag to satisfy this indication. Specifically, when theencryption flag is set to ‘2’ the encryption flag means that the keyused to protect this data set is stored in a KSDS and the Copy of AADField actually contains a pointer to which shred key in which KSDS wasused. With this assumption, using “W(a, b)” to mean a key ‘a’ wrappedwith another key ‘b’ and that the tape drive is served a key from anoutside key manager called the Served key (Sk). The following willdescribe the a secure option, where the mechanisms of the presentinvention are using both transparent encryption (e.g. LME) to protectthe cartridge and File Level Encryption to allow Secure (cryptographic)erasure of select encrypted data written to tape shredding on a per filebasis. It should be noted that the illustrated embodiments may stillhave the base File Level Encryption to enable shredding without use oftransparent encryption or externally served keys. Thus, the followingconfiguration may be applied:

User Data Set (LTO-5 Case, Meaning with Indirection):All data in the Data Set is encrypted with a drive Generated key (Gk)

In Dataset Information Table (DSIT):

Encrypted Flag=2

Wrapped Key field=W(Gk, Fk)

Copy of AAD Field=pointer to location of Fk (i.e. which key in whichKSDS)

KSDS:

All keys in the KSDS are encrypted with a drive generated key store key(KSk)

In Dataset Information Table (DSIT):

Encrypted Flag=3 (to represent this KSDS encryption technique)

Wrapped Key Field=share of W(KSk, Sk)

Copy of AAD field=the key label the external key manager needs to fetchSk

It should be noted that in the Wrapped Key Field the mechanisms are onlystoring a share of W(KSk, Sk). The mechanisms may not create W(KSk, Sk)unless the mechanisms have a proper threshold (> or =M) per the Shamirkey split. In such a case the follow configuration may be applied:

User Data Set (LTO-5 Case):

All data in the Data Set is encrypted with a drive Generated key (Gk)

In Dataset Information Table (DSIT):

Encrypted Flag=2

Wrapped Key field=W(Gk, Fk)

Copy of AAD Field=pointer to location of Fk (i.e. which key in whichKSDS)

KSDS:

All keys in the KSDS are encrypted with a drive generated key store key(KSk)

In Dataset Information Table (DSIT):

Encrypted Flag=4 (to represent this KSDS encryption technique)

Wrapped Key Field=share of W(KSk)

Copy of AAD field=<empty>

Moreover, to further describe method 1, consider that a LTO-5 KSDS wouldnominally be 115 mm long (it will be shorter in LTO-6 because the lineardensity is increased), so to store 16 nominally requires 1.84 meters oftape.) The nominal distance between LP2 and LP3 is 8 meters, so there isnominally room to write a set of 16 KSDSs more than four times betweenLP2 and LP3 on a given wrap in a given direction. It may be assume thateach KSDS may be written four times, twice in the forward direction onone wrap (from LP2 to LP3), and twice in the reverse direction onanother wrap (from LP3 to LP2). For each 16 KSDSs which can be stored,16×60K˜=1M keys can be stored. There may be ample room to write a set of16 KSDSs multiple times between LP2 and LP3 on a given wrap in a givendirection, which is described in more detail below. If a pair of wraps,one forward and one reverse, in this LP2-LP3 region, is dedicated tostoring a given set of 16 KSDSs, then it may be stored 4 times in a waywhich gives more than adequate redundancy. There may be at least 12 suchwrap pairs available on an LTO-5 cartridge, so roughly 10 million keyscould be accommodated. Also, other options for storing even more keysare discussed below. It should be noted that writing 16 KSDS at a timemeans 16×2.4 MB=38.4 MB are written and if that is the content, about 48MB of memory space may be consumed. If the original is taken and performa Shamir key split into 4 shares, and store those in memory in additionto the initial unsplit 48 MB, 5×48 MB=240 MB of memory total may berequired. If more than 10 million keys are truly needed, then the methodmay be extended and modified (e.g. create a separate partition to storeKSDSs in which case many, many more can be stored, potentially openingthe door to encrypting many more than 10 million files each with adifferent encryption key).

It should be noted that there are several different strategies to pursuewith respect to writing the KSDS. One option is pre-generating all thekeys, thereby only requiring KSDS overwrite for erase. In this case, itis sufficient to not use all of the keys, because it is sufficient toleave remnants when new data is added—only an assured delete is requiredwhen keys are removed/shredded. There is a performance advantage for notrequiring a KSDS update on new index boundaries (otherwise this wouldresult in long locate/write/locates during what could otherwise bestreaming writing). A new option, for example, may be referred to as“Command 1” in the set data encryption page of the SPOUT command. A SPINcommand requesting the Data Encryption Status page would then follow toretrieve the key label in the KAD data. To do a write append, a subsetof Command 1 may be performed. In other words, the new option in the SetData Encryption page of the SPOUT command is performed.

The second new option may be referred to as a “Command 2” where the Jagkey shred command is vendor-specific. For a standardized command,something new needs to be added to the standard and this may be a newcommand that passes the key label and indicates to shred the key relatedto the label.

In one embodiment, a new encryption method is performed that is referredto as “Method 2.” The first encryption method, previously described,provides the necessary shreddability functionality even when tapeencryption is used in the prevalent ways certain tape encryption is usedtoday—which is specifically tape encryption with a single encryptionkey. A transparent tape encryption method (whether LME or SME (for z/OSor Open)) may essentially encrypt the entire cartridge using a singleserved key. Transparent tape encryption may be more prevalently deployedtape encryption model but the mechanisms may also support AME. The AMEmay be managed one of two ways. The AME may choose to encrypt all thedata with a single key (what TSM does). However, the T10 command setalso allows AME keys to be changed on a per block basis. Also, method 1does not allow for encryption keys to be changed frequently, since agiven Data Key becomes entangled with a large number of shred keys in aKSDS because it is used to encrypt it. Thus, this second encryptionmethod (method 2) enables a large number of tape encryption keys, allowsfor frequent key changes, and/or allows for frequent changes betweenwriting of encrypted data and unencrypted data, as allowed by the T10tape encryption model. This is achieved by writing KSDSs without anydependence on a served key. Instead, a drive-generated key only protectsthe KSDS's for protecting the key store—and this is only for thepurposes of enabling a Shamir key split. Security is not a problembecause the shred keys will not be used directly to encrypt a tapecartridge. Similarly, served keys cannot be used directly to encryptuser data, because there would be no dependence on the shred keys, andthus, the ability to shred data is lost. Instead an encryption key willprotect user data, which is dependent on both the served keys and theshred keys. The two keys are combined via a key derivation function(KDF). It should be noted that there may be different types of KDFs. OneKDF may be to either calculate a simple hash (e.g. SHA-256) across aconcatenated data field, which includes both the served key and theshred key. Alternately, another KDF may use a hash-based messageauthentication code (HMAC) (which is based on a hash function). AnotherKDF may encrypt one with the other (e.g. encrypt the shred key with theserved key) and use the encrypted result as the key to protect userdata. An acceptable KDF may be selected that may process a served keyand a shred key into a resultant derived key. The resultant derived keyprotects the user data in the same way a served key is used today. Forexample, in the LTO-4 case the resultant derived key could be used toencrypt user data directly. Also, in the LTO-5, the resultant derivedkey may be used indirectly to wrap a drive generated encryption key.With the LTO-5, the drive generated encryption key may be the oneactually used to encrypt user data.

Exact Controls from a LTO Logical Format POV—Method 2

In each dataset, a need exists for pointing a tape drive to the twoitems it must input to a KDF to find the key used to protect the userdata. As will be described below, in one embodiment, the illustratedembodiments may be applied to LTO-5 (which may be adopted by the LTO-6).The Landsat Technical Working Group (LTWG) should determine the best wayfor this indication, and in one embodiment, a new state is created forthe existing encrypted flag to satisfy this indication. Specifically,when the encryption flag is set to ‘2’ the encryption flag means thatthe key used to protect this data set is stored in a KSDS and the Copyof AAD Field actually contains a pointer to the shred key in which KSDSwas used. Using the nomenclature “W(a, b)” to mean a key ‘a’ wrappedwith another key ‘b’ And assuming that the drive is served a key from anoutside key manager called the Served key (SeK) and that there exists anassociated Shred key (ShK) in a KSDS, the following configuration may beused:

KDF:

SeK and ShK are combined to produce a Derived key (Dk)User Data Set (LTO-5 Case, Meaning with Indirection):All data in the Data Set is encrypted with a drive Generated key (Gk)

In Dataset Information Table (DSIT):

Encrypted Flag=2

Wrapped Key field=W(Gk, Dk)

Secure (cryptographic) erasure of select encrypted data written to tape

[new] Shred Key Pointer=location of ShK (i.e. which key in which KSDS)

Copy of AAD Field=the key label the external key manager needs to fetchSeK

KSDS:

All shred keys in all KSDSs are encrypted with a drive generated keystore key (KSk)

In Dataset Information Table (DSIT):

Encrypted Flag=3

Wrapped Key Field=Shamir share of KSk

Copy of AAD field=<empty>

It should be noted that in the Wrapped Key Field only a share of the KSkis stored. The mechanisms may not recreate KSk unless the mechanismshave a proper threshold (> or =M) per the Shamir key split.

In one embodiment, a new encryption method that is referred to as“Method 3” is indicated. The third method considered, is similar tomethod 2, except the KSDS are allowed to be protected by an externallyserved Cartridge key (Ck). In this way, the Shred keys may not be readin the clear even if a user gets a hold of the cartridge. It should benoted that method 3 is introducing a cartridge global served key, whichis another obstacle to transparency. Attempting method 3 from the start(e.g. when shred keys are generated) is problematic and only makes senseif a drive may definitively know that all encryption will be done with asingle served key. Although the drive does not know all encryption willbe done with a single served key, the illustrated embodiments mayindicate the encryption will be done with a single served key after thefact. For example, if a cartridge is encrypted with LME, then thecartridge is encrypted with a single key. If that cartridge is writtenby an application, such as TSM or NBU, then the cartridge is typicallystreamed full. The drive may detect that the cartridge was streamed fulland all encrypted with a single key. In this case, the mechanisms may goback and then protect the shred keys in the KSDS's with that sameencryption key thereby preventing these shred keys from being read, evenwith an instrumentation drive. Whether the mechanisms put in place achange so that the drive knows that the drive will be encrypted with asingle key a priori or whether the drive figures that out for itself bythe way the cartridge was written/encrypted, either way the mechanismsmay protect the KSDS by setting the just discussed Ck to SeK. It shouldbe noted that if the mechanisms go the route of having the drive figureout the drive will be encrypted with a single key a priori, in oneembodiment, the KSDS's would be encrypted from the start protected byCk, and the Ck then would be stored as a separate entity (in an EEDKtype structure, though at this point the Ck is not wrapped withanything). Then, if the drive determines the cartridge was protected bya single encryption key, the drive may go and wrap Ck with the SeK tocreate a new EEDK, which the drive then writes (securely) over theprevious EEDK (as if it were rekeying the EEDK, though in this case“wrapping the encryption key which encrypted the shred keys” would bemore accurate). The following configuration may be used:

KSDS:

All shred keys in all KSDSs are encrypted with a drive generated keystore key (KSk)

In Dataset Information Table (DSIT):

Encrypted Flag=1

Wrapped Key Field=Shamir share of W(KSk, Ck)

Copy of AAD field=the key label the external key manager needs to fetchCk

In one embodiment, methods 2 and 3 enable the shred and encryption to becompletely independent. Methods 2 and 3 both allow for completeindependence of shred keys and encryption keys. Thus one application(e.g. LTFS) may be changing shred keys on whatever boundary made senseto the application (e.g. at file boundaries) and a completelyindependent entity (e.g. HP's SKM) may be working inter-operatively withthe drive to change encryption keys on some other boundary that madesense to the application (e.g. write append boundaries). Thus, a givenshred key may span through use of multiple encryption keys. The converseis also true in that a given encryption key may span through use ofmultiple shred keys so the two types of keys may transition completelyindependently of one another.

To further illustrate the mechanisms of the present invention, a FileUsing Application may write data to tape via LTFS, as will be describedin FIG. 3 and FIG. 4. An LTFS may be configured to encrypt each filewith a separate key. The File Using Application may later delete eachfile encrypted with a separate key. LTFS may be configured to do asecure (cryptographic) erasure of a file when it is deleted. If so, LTFSwould delete the keys used to encrypt that file data and thendefinitively erase and then rewrite the KSDS in a way, which isresilient against common errors (such as servo errors) and still preventeven forensic data recovery of that data. The illustrated embodiment maybe applied to any data tape technology (e.g. IBM's 3592, Oracles T10000,etc.), which has the equivalent of a Housekeeping Dataset area, even ifthat tape technology is not LTO based and any sequentially writtenstorage, even if it is not tape—e.g. CD or DVD.

Turning to FIG. 4, a flowchart illustrating an exemplary method 400 forcryptographic erasure of selected encrypted data is depicted. The method400 begins (step 402). The method 400 may configure data files withderived keys, the derived keys adapted to be individually shredded in asubsequent erasure operation and allow for cryptographic erasure ofselected encrypted data in the data files without necessitating at leastone of removal and rewrite of retained data (step 404). The method 400ends (step 406).

Turning now to FIG. 5, a flowchart illustrating an exemplary method 500for cryptographic erasure of selected encrypted data with derived keysis depicted. The method 500 begins (step 502). The method 500 mayconfigure data files with derived keys, the derived keys adapted to beindividually shredded in a subsequent erasure operation and allow forcryptographic erasure of selected encrypted data in the data fileswithout necessitating at least one of removal and rewrite of retaineddata (step 504). The derived keys are divided into at least two parts(step 506). Redundant data of the two parts may be deleted together. Thederived keys are placed in a key store data set (“KSDS”, e.g., a keyfile) (step 508). A label for each of the derived keys is provided (step510). A pointer may be used to associate the selected encrypted datawith the KSDS (step 512). The method 500 may shred the label and the twokey parts of selected encrypted data (step 514). It should be noted thatfailure to shred each of the at least two key parts does not prohibitthe shredding. The method 500 may rewrite the KSDS without the deletedlabel and the two deleted key parts (step 516). An external reading ofthe derived keys is prevented by overwriting the divided keys in theKSDS (step 518). Thus, forensic recovery means are prohibited fromaccessing the erased selected encrypted data. The method 500 ends (step520)

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that may contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wired, optical fiber cable, RF, etc., or any suitable combination of theforegoing. Computer program code for carrying out operations for aspectsof the present invention may be written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Java, Smalltalk, C++ or the like and conventionalprocedural programming languages, such as the “C” programming languageor similar programming languages. The program code may execute entirelyon the user's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described above with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, may be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that may direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks. The computer program instructions may also beloaded onto a computer, other programmable data processing apparatus, orother devices to cause a series of operational steps to be performed onthe computer, other programmable apparatus or other devices to produce acomputer implemented process such that the instructions which execute onthe computer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagram in the above figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock might occur out of the order noted in the figures. For example,two blocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, may be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

While one or more embodiments of the present invention have beenillustrated in detail, one of ordinary skill in the art will appreciatethat modifications and adaptations to those embodiments may be madewithout departing from the scope of the present invention as set forthin the following claims.

What is claimed is:
 1. A method for cryptographic erasure of selectedencrypted data by a processor device in a computing environment, themethod comprising: configuring data files with a plurality of derivedkeys, the plurality of derived keys adapted to be individually shreddedin a subsequent erasure operation, wherein the plurality of derived keysallow for cryptographic erasure of the selected encrypted data in thedata files without necessitating at least one of removal and rewrite ofretained data.
 2. The method of claim 1, further including, dividingeach of the plurality of derived keys into at least two key parts,wherein redundant data of the at least two parts are deleted together.3. The method of claim 1, further including placing the plurality ofderived keys in a key store data set (KSDS), wherein a label is providedfor each of the at least two key parts.
 4. The method of claim 3,further including shredding the label and the at least two key parts ofthe selected encrypted data, wherein failure to shred each of the atleast two key parts does not prohibit the shredding.
 5. The method ofclaim 4, further including rewriting the KSDS without the deleted labeland the at least two deleted key parts.
 6. The method of claim 5,further including preventing an external reading of the plurality ofdivided keys by overwriting the plurality of divided keys in the KSDS,wherein forensic recovery means are prohibited from accessing the erasedselected encrypted data.
 7. The method of claim 3, further including, inconjunction with the placing the plurality of derived keys in the KSDS,using a pointer to associate the selected encrypted data with the KSDS.8. The method of claim 1, further including performing thecryptographically erasing of the selected encrypted data in the datafiles via a plurality of applications, wherein the performing occurs ina plurality of data tape technology and sequentially written storagedevices.
 9. A system for cryptographic erasure of selected encrypteddata in a computing environment, comprising: at least one tape drive,and at least one processor device connected to the at least one tapedrive operable in the computing environment, wherein the at least oneprocessor device is adapted for: configuring data files with a pluralityof derived keys, the plurality of derived keys adapted to beindividually shredded in a subsequent erasure operation, wherein theplurality of derived keys allow for cryptographic erasure of theselected encrypted data in the data files without necessitating at leastone of removal and rewrite of retained data.
 10. The system of claim 9,further including, dividing each of the plurality of derived keys intoat least two key parts, wherein redundant data of the at least two partsare deleted together.
 11. The system of claim 9, wherein the processordevice is further adapted for placing the plurality of derived keys in akey store data set (KSDS), wherein a label is provided for each of theat least two key parts.
 12. The system of claim 11, wherein theprocessor device is further adapted for shredding the label and the atleast two key parts of the selected encrypted data, wherein failure toshred each of the at least two key parts does not prohibit theshredding.
 13. The system of claim 12, wherein the processor device isfurther adapted for rewriting the KSDS without the deleted label and theat least two deleted key parts.
 14. The system of claim 13, wherein theprocessor device is further adapted for preventing an external readingof the plurality of divided keys by overwriting the plurality of dividedkeys in the KSDS, wherein forensic recovery means are prohibited fromaccessing the erased selected encrypted data.
 15. The system of claim11, wherein the processor device is further adapted for, in conjunctionwith the placing the plurality of derived keys in a key store data set(KSDS), using a pointer to associate the selected encrypted data withthe KSDS.
 16. The system of claim 9, wherein the processor device isfurther adapted for performing the cryptographically erasing of theselected encrypted data in the data files via a plurality ofapplications, wherein the performing occurs in a plurality of data tapetechnology and sequentially written storage devices.
 17. A computerprogram product for cryptographic erasure of selected encrypted data ina computing environment by a processor device, the computer programproduct comprising a non-transitory computer-readable storage mediumhaving computer-readable program code portions stored therein, thecomputer-readable program code portions comprising: a first executableportion for configuring data files with a plurality of derived keys, theplurality of derived keys adapted to be individually shredded in asubsequent erasure operation, wherein the plurality of derived keysallow for cryptographic erasure of the selected encrypted data in thedata files without necessitating at least one of removal and rewrite ofretained data.
 18. The computer program product of claim 17, furtherincluding a second executable portion for dividing each of the pluralityof derived keys into at least two key parts, wherein redundant data ofthe at least two parts are deleted together.
 19. The computer programproduct of claim 17, further including a second executable portion for,placing the plurality of derived keys in a key store data set (KSDS),wherein a label is provided for each of the at least two key parts. 20.The computer program product of claim 19, further including a thirdexecutable portion for shredding the label and the at least two keyparts of the selected encrypted data, wherein failure to shred each ofthe at least two key parts does not prohibit the shredding.
 21. Thecomputer program product of claim 20, further including a fourthexecutable portion for rewriting the key files without the deleted labeland the at least two deleted key parts.
 22. The computer program productof claim 21, further including a fifth executable portion for preventingan external reading of the plurality of divided keys by overwriting theplurality of divided keys in a key store data set (KSDS), whereinforensic recovery means are prohibited from accessing the erasedselected encrypted data.
 23. The computer program product of claim 19,further including a third executable portion for, in conjunction withthe placing the plurality of derived keys in a key store data set(KSDS), using a pointer to associate the selected encrypted data withthe KSDS.
 24. The computer program product of claim 17, furtherincluding a second executable portion for performing thecryptographically erasing of the selected encrypted data in the datafiles via a plurality of applications, wherein the performing occurs ina plurality of data tape technology and sequentially written storagedevices.